Franchising is an approach to doing business whereby the owner of a business concept (i.e., a Franchisor) licenses the business model to an independent business entity (i.e., a Franchisee) to operate under the terms of a well defined franchise agreement. The Franchisor authorizes the usage of proven trade dress, operating methods and systems as well as business practices within the guidelines set forth in the agreement. The Franchisor provides various support services that can include advertising/marketing/public relations, training, operating/physical facility design assistance, product/menu specifications, materials sourcing support, production and operating systems design including Line of Business (LOB) applications, Point of Sales (POS) systems and/or other business support. Such support is generally provided to the Franchisee for a royalty fee calculated as a percentage of gross monthly sales which the Franchisee typically faxes or emails to the Franchisor on a monthly basis. In the US, as of 2005, the franchising business model was utilized in over 70 different industry segments by 2,500 Franchisors with over 900,000 individual franchisee locations generating more than $1 trillion in revenues. An LOB application is one of the set of critical computer applications that are vital to running a business, such as production, operations, accounting, supply chain management, resource planning applications, and the like. LOB applications are usually specialized programs that contain a number of integrated capabilities which tie into and depend upon the features of databases and database management systems to store, retrieve and manage critical transaction and business data.
Franchisors have a fiduciary legal obligation to support the franchisees in their efforts to successfully operate the concept. Unfortunately, Franchisors typically struggle to know how their Franchisees are performing as it is very difficult to collect, consolidate and report on the key operational and financial indicators for each of the Franchisees. At least one known reason for this difficulty is because many of these individual Franchisees utilize different operational and financial reporting systems that cannot be easily collected from, consolidated or reported upon due to their different data storage formats, different product versions or non-standardized product deployment. As a result, Franchisors are often left to advise Franchisees on how to improve their business and operational performance with very limited data and they lack the ability to compare them to peer groups and or regional norms within the concept or industry. Additionally, while most businesses and business consultants desire to identify operational Key Performance Indicators (KPI), having limited data makes it difficult to identify and monitor them.
While Franchising is one example of an industry that can utilize a remote data collection system, there are many other industries or business models which can benefit from a remote data collection system. Other examples include trade associations, co-operatives, or distributors but can also include branch or field offices of large corporate enterprises. Another example is a bank or credit provider who desires to monitor the financial health of one or more businesses to which they make loans or to whom they extend lines of credit which can be tied to financial measurements such as accounts receivable (AR), cash flow or profitability. Typically, businesses who desire to remotely monitor the financial or operational parameters of a business depend on emailed or faxed copies of monthly, quarterly or year-end reports which are often lost, ignored or obsolete by the time they are received or reviewed. In addition, these reports are inadequate to monitor dynamic business conditions and certainly cannot provide monitoring in a near real time and consolidated manner without extensive customized Information Technology (IT) systems and support personnel. In general, the problem and challenges of remote data collection can be seen to apply to any and all business with multiple locations where POS or LOB applications operate and where the need to monitor these businesses requires access to the data from each location in a consolidated or “rolled up” fashion.
In at least some known techniques of collecting operational or business data, collection features embedded into a single LOB application such as a POS system are generally standardized across all remote sites. That is, if a Franchisor wishes to collect each day's sales and transaction detail information from all of the remote stores operating in their franchise system, they must first standardize every store on the exact same POS system vendor (if not the exact same version of that POS application). This standardization is required to enable the system to roll up and consolidate the data from identical copies of the application database along with identical transaction detail format which is stored in the same type and version level of the database. Additionally, many of these single version collection systems depend on data consolidation systems that are built into the database engine which is used to store (electronically read/write to a disk) the data at the remote sites. Database vendors such as Microsoft, Oracle, and Sybase have provided many types of proprietary “data replication” techniques embedded into their products to allow Independent Software Vendors (ISVs) to develop rich LOB applications (e.g. POS) that can copy and replicate identical databases to a central location via their built-in techniques or Application Programming Interfaces (API). The fact that a business must standardize their POS system on a single POS vendor and version to enable remote data consolidation is a limitation which is often driven by the fact that the POS system was built on top of a database vendor's replication technology which only “talks” to itself.
Previous custom IT solutions to these challenges utilized data replication techniques which required the development of custom software using proprietary tools and technologies. While database or software tool vendors have provided remote data replication techniques for many years, these techniques are limited to being used on themselves: e.g., a single database vendors API and replication system can be used to build a single LOB application (ex. a CRM system or a POS) which only collects and consolidates remote data from of the same LOB type and version level. These techniques do not allow for a generic process which works both across LOB applications and across database vendors in a simplified and automated, lights out manner. Additionally, while traditional “middleware” message bus (or message queuing) architectures have been used by large enterprise businesses to replicate data between two independent LOB systems, these implementations require a consistent set of centrally managed and expensive IT infrastructure (such as integrated security models, managed firewall ports or private networks, and dedicated servers). Thus, businesses desiring to replicate data from multiple remote sites or multiple LOB systems must either standardize on one database or middleware vendor and or provide extensive IT development and support at every site.
Alternative techniques to replicate data depend on a common definition of the data and or a common data file format. While there are many industry standards for “data interoperability” (such as XML standards, CSV text files, or other formats) these standards only enable a common data description and data format to be used when “exporting” data from within the original LOB system, they do not solve the data transport problem. Thus additional communication technologies such as the Internet File Transfer Protocol (FTP) or Message Queuing products from Tibco, IBM, Oracle/BEA, and others must be used. Or alternatively, custom software can be written that utilizes the new Web Services communication standards to “transport” the common data formatted file to a central location. The challenge to using these techniques to create a centralized and automated remote data consolidation system is the fact that they require software customization to adapt them to each LOB product and version as well as require extensive IT personnel to support the communication infrastructure on both sides of the communication channel. In addition, these methods depend on having every LOB application support the same common file format as a “data export” option. An additional requirement may be present when data from different LOB applications is collected into a central data warehouse or repository which then requires that extensive “data transformation” techniques be used to normalize the data into a common format. These conditions or requirements cannot be easily supported by small or mid-size businesses (ex. Franchisors) or these conditions do not exist uniformly across various remote businesses. This fact is particularly true for remote sites where the local personnel may not be employees of the business which seeks to centralize the data (ex. Franchisees) and thus they are unfamiliar with, untrained on or unwilling to follow detailed operational guidelines and procedures to extract LOB data from their local system into a common data file and send it across a sophisticated communication infrastructure.
An additional challenge to automated collection of remote LOB data is the problem of systems administration and management. For any system to work, it must have a process to uniquely identify a location and the specific “rules” required by the local system agent to operate autonomously at the location. This identification and control scheme must handle variations and changes in business operating rules, naming conventions, organizational structure (regions, attributes, reporting rules, etc) and other collection and consolidation rule requirements such as versioning of code and databases. Additionally, the systems management model must provide for flexibility in targeting, controlling, monitoring and reporting on the state of the remote sites while the data collection process dynamically operates on a 24×7×365 manner. Beyond the technical barriers, many remote data collection systems fail due to the overhead and complexity of simply managing remote software agents at hundreds or even thousands of remote physical locations. Finally, the communication method utilized to connect the remote sites to a central consolidation point must be easy and operate in a “lights out” manner in order to efficiently scale the management, monitoring and system control while providing for fault tolerance, reliability and guaranteed delivery of remote data to the central site.
Thus, any business which desires to have a consolidated view of LOB data across many remote sites must either provide IT support personnel, or create a custom software program that is so simple that anyone can operate it without extensive training on consistent procedures. What is desired by various businesses is a generic remote data consolidation system which can be quickly and easily adapted to their LOB system without extensive and costly custom programming. This generic system must then work across any type of remote location and work across various LOB application and database vendors as well as multiple databases or LOB applications at a single remote site. Such a system would then need to be quickly deployed to many remote sites without remote IT personnel, work flexibly and yet dynamically, reliably and automatically collect data from one or more various LOB applications and send the data across a common communication infrastructure such as TCP/IP and the Internet.